The IP Multimedia Subsystem (IMS) is an architectural framework for delivering Internet Protocol (IP) multimedia services. It constitutes an approach to providing internet based multimedia services, including voice calls and messaging, to various wireless telecommunications networks, such as Global System for Mobile Communications (GSM), wireless LAN, and Universal Mobile Telecommunications System (UMTS), as well as fixed line networks. One of the protocols used in the IMS network is the Session Initiation Protocol (SIP). A terminal used with the IMS network is referred to as SIP terminal.
FIG. 1 shows the architecture for handling a terminating IMS call, whereby the call is offered to a GSM terminal of the called subscriber. FIG. 1 also shows a SIP terminal; the called subscriber may have both a GSM terminal and a SIP terminal. This architecture is used for IMS Mobility (also known as Multi Access Extension, MAE). A subscriber of such a network service, i.e. an MAE subscriber, has access to IMS services and may use a GSM terminal or a SIP terminal for call establishment and call reception. The subscriber may receive a call and answer that call on his GSM terminal or on his SIP terminal.
The Serving Call Session Control Function (S-CSCF) is an entity in the IMS network that handles incoming and outgoing calls in the IMS network. In FIG. 1, an S-CSCF 10 receives an incoming call establishment request message destined for an MAE subscriber, who has a GSM terminal and a SIP terminal. The call may be offered on both the MAE subscriber's GSM terminal and the MAE subscriber's SIP terminal. For the offering of the call to MAE subscriber's SIP terminal, the S-CSCF 10 communicates with a proxy CSCF (P-CSCF) 12 using SIP, and the P-CSCF 12 forwards the call establishment request message to the SIP terminal 14. The S-CSCF uses, for above-described routing of the call towards P-CSCF and SIP terminal, a contact address that the SIP terminal had previously deposited in the S-CSCF, during the registration of the SIP terminal in the IMS network.
For the offering of the call to MAE subscriber's GSM terminal 24, the S-CSCF 10 communicates with a Media Gateway Controller (MGC) 16, using SIP signalling. The MGC 16 contains a Media Gateway Control Function (MGCF), which, among others, converts the SIP signalling into ISUP signalling (ISDN user part, a call establishment signalling protocol for ISDN networks and GSM networks). That is, the MGC 16 terminates the SIP signalling from the IMS core network and establishes the terminating call leg in the GSM network, towards the called subscriber's GSM terminal. The MGC 16 sends a call establishment request message to the Gateway Mobile Services switching Centre (GMSC) 18 in the GSM network. This call establishment request message may be an ISUP Initial Address Message (IAM). The GMSC 18 requires routing information in order to be able to forward the call towards the Mobile Services switching Centre (MSC) currently serving the GSM terminal 24. Hereto, the GMSC communicates, using MAP (Mobile Application Part) signalling, with a Home Location Register (HLR) 20. The HLR 20 is a database that contains subscription and location details of the subscribers that are authorized to use the GSM network that this HLR forms part of. The HLR 20 receives the MAP signalling message from the GMSC 18 and requests routing information, in the form of a Mobile Station Roaming Number (MSRN), from a visited MSC (VMSC) 22. The VMSC has a Visitor Location Register (VLR, not shown) integrated in it. The HLR stores the VMSC address for each subscriber of the network. That facilitates the HLR to contact the VMSC for requesting an MSRN. The VMSC 22 supplies the MSRN of the called GSM terminal 24 back to the HLR 20, and the HLR 20 forwards this to the GMSC 18. The GMSC 18 may then use the MSRN to forward the call to the VMSC 22; the VMSC may then offer the call to the GSM terminal 24.
The MGCF may be located in a separate device, the MGC 16, as described here, or incorporated within the GMSC 18 in which case the S-CSCF 10 communicates directly with the integrated MGCF & GMSC.
When a subscriber has answered a call, it is important for the operator to know on which device the call was answered and, especially in the case of answering the call on a GSM terminal, the location of the GSM terminal. The location of the GSM terminal, when answering the call, may be used for, among other things, terminating call charging. When a call is answered on a GSM terminal, there may be cost associated with it, especially when the person answering the terminal is currently residing in a foreign network, i.e. the location of the GSM terminal at the time of answering the call is important information. When a call is answered on a SIP terminal, there are normally no charges associated with this terminating call.
Within SIP, the location of a terminal may be reflected in a designated SIP header in SIP request messages and SIP response messages. This header is the P-access-network-info (PANI) header. The SIP terminal in FIG. 1 may for example report its location when returning SIP messages to the P-CSCF 12 when answering a call. The PANI is defined in IETF RFC 3455. 3GPP has specified further enhancements to PANI in 3GPP TS 24.229, to cater for a variety of access network types.
A problem with the contemporary solution for offering a call to multiple terminals, including a GSM terminal, is that the MGCF does not have access to any location information of the called subscriber's GSM terminal 24. Hence, the SIP signalling generated by the MGC 16 towards the IMS core network, more specifically, response messages such as 180 Ringing, 183 Session Progress or 200 Ok, do not contain the PANI header. Therefore, it is not possible to provide the called subscriber's GSM terminal location information transparently, i.e. within the call establishment signalling, to the IMS core network with the current network implementation.
The SIP response(s) generated by the MGC 16, related to the SIP Invite message sent from the S-CSCF 10 toward the GSM terminal via MGCF, will contain a Contact header. The Contact header is a designated SIP header comprising an address that can be used for addressing subsequent address messages to that entity (MGCF), for the remainder of the SIP dialogue. The Contact header may be placed in a charging record that is generated by entities such as S-CSCF or SIP application server. The charging record may be used off line, to determine whether the subscriber answered the call on his/her SIP terminal 14 or on his/her GSM terminal 24. However, the Contact address from the MGC 16 will typically be an IP address of that MGCF; this follows from the fact that the SIP signalling terminates in the MGCF. The MGCF converts the SIP signalling into ISUP signalling. Using this MGCF Contact address to determine whether the call was answered on a GSM terminal would require that the IP address of the MGC 16 be configured in the off line charging system, to be able to recognize it as an address associated with the MGC 16 and hence to ascertain that the call was answered on a GSM terminal. This method of using Contact address is further hampered by the fact that the signalling between S-CSCF 10 and the MGC 16 may traverse an Interconnect Border Control Function (IBCF, not shown) replacing the Contact header. An IBCF is used as border gateway between two IMS networks or between an IMS network and a circuit switched (CS) network such as a GSM network. This method of using Contact address also does not provide any location information of the GSM terminal 24. The Contact address relates to the MGCF and is not related to the location of the GSM terminal.
This limitation of the current solution has the effect that the IMS core network has insufficient capability for terminating call handling (it does not know the location of the called subscriber's GSM terminal and hence cannot act on it within service logic processing) and has the further effect that charging record correlation may be needed to correlate GSM charging records, containing the location information, with IMS based charging records, containing other relevant data of the call. Correlation of charging records of the IMS network with charging records of the GSM network is technically feasible, but is generally costly and processing intensive.
Various solutions exist for providing location information of the called party's GSM terminal to the IMS network.
As shown in FIG. 1, the S-CSCF 10 has access to at least one IMS service 26, such as IP Centrex (network based PBX), that is controlling the terminating call to the IMS subscriber. The IMS service 26 might apply a Subscriber location query using Any Time Interrogation (ATI), which is a MAP procedure specified in the CAMEL standard. By using ATI, the IMS service may obtain the subscriber location (Cell Id and/or geographic coordinates) and the subscriber status (Idle, Busy, Detached).
The IMS service 26 would send MAP ATI directly to the HLR 20, which sends a MAP Provide Subscriber Information (PSI) message to the VMSC 22. The VMSC 22 provides the requested information to the HLR 20, which forwards the information directly to the IMS service 26.
This method of using ATI has the following disadvantages:                IMS services like IP Centrex or similar, do not generally support SS7 protocol stack, so cannot support MAP operations. Implementing SS7 in these service nodes is often not feasible or is expensive.        When the IMS service 26 is handling a terminating call to a subscriber, it may not know what device(s) the subscriber has, i.e. the IMS service 26 would not know whether the subscriber has a GSM device, possibly in combination with a SIP device. The fact that the IMS service does not have this knowledge available is intrinsic to the IMS network architecture. The public user identity that is used to call the subscriber, e.g. sip:john.smith@company.se or tel:+46702983789 is not an indication of the type of terminal used by the subscriber.        Should the IMS service 26 apply MAP ATI and obtain the subscriber's GSM terminal location, then even when the call is established to the subscriber, the IMS service 26 may still not know whether the call was answered on the GSM terminal 24 or on the SIP terminal 14. As explained earlier, this knowledge is important for the purpose of charging.        Applying the location query prior to establishing the call to the subscriber results in additional call establishment time.        When using ATI for the purpose of obtaining the called party's location information, such ATI query would need to be performed for each and every IMS service that needs this information. Multiple IMS services may be invoked for a call to an IMS subscriber.        
There is therefore a need for an improved method and apparatus for providing location information of a mobile terminal from the GSM network to the IMS network.